For some computer programs, it is critical that steps in the program are performed within defined time periods, or at defined times. Examples of such programs are control programs for operating mobile telephones, or for operating private branch exchanges (PBXs) or cellular base stations. Typically, the program must respond to external events or changes of state in a consistent way, at or within a certain time after the event. This is referred to as operating in “real time”.
For many other programs, however, the time taken to execute the program is not critical. This applies to most common computer programs, including spreadsheet program, word processing programs, payroll packages, and general reporting or analysis programs. On the other hand, whilst the exact time taken by such programs is not critical, in most cases, users would prefer quicker execution where this is possible.
Applications programs interact with the computers on which they run through operating systems. By using the applications programming interface (API) of the operating system, the applications program can be written in a portable fashion, so that it can execute on different computers with different hardware resources. Additionally, common operating systems such as Linux or Windows provide multi-tasking; in other words, they allow several program to operate concurrently. To do so, they provide scheduling; in other words, they share the usage of the resources of the computer between the different programs, allocating time to each in accordance with a, scheduling algorithm. Operating systems of the this kind are very widely used, but they generally make no provision for running real time applications, and they therefore are unsuitable for many control or communications tasks.
For such tasks, therefore, real time operating systems have been developed; one example is ChorusOS (also known as Chorus) and its derivatives. Chorus is available as open source software.
It is described in “ChorusOS Features and Architecture overview,” Francois Armand, Sun Technical Report, August 2001, 222p.
These operating systems could also be used to run other types of programs However, users understandably wish to be able to run the vast number of “legacy” programs which are written for general purpose operating systems such as Windows or Linux, without having to rewrite them to run on a real time operating system.
It would be possible to provide a “dual boot” system, allowing the user to run either one operating system or the other, but there are many cases where it would be desirable to be able to run a “legacy” program at the same time as running a real time program. For example, telecommunications network infrastructure equipment, third generation mobile phones and other advanced phones, and advanced electronic gaming equipment may require both realtime applications (e.g. game playing graphics) and non-realtime applications (game download).
In U.S. Pat. No. 5,903,752 and U.S. Pat. No. 5,721,922, an attempt is made to incorporate a real time environment into a non real time operating system by providing a real time multi-tasking kernel in the interrupt handling environment of the non real time operating system (such as Windows).
One approach which has been widely used is “emulation”. Typically, an emulator program is written, to run under the real time operating system, which interprets each instruction of a program written for a general purpose operating system, and performs a corresponding series of instructions under the real time operating system. However, since one instruction is always replaced by many, emulation places a heavier load on the computer, and results in slower performance. Similar problems arise from the approach based on providing a virtual machine (e.g. a Java™ virtual machine). Examples of virtual machine implementations are EP 1059582, U.S. Pat. No. 5,499,379, and U.S. Pat. No. 4,764,864.
A further similar technique is described in U.S. Pat. No. 5,995,745 (Yodaiken). Yodaiken describes a system in which a multi tasking real time operating system runs a general purpose operating system as one of its tasks, pre-empting it as necessary to perform real time tasks.
Another approach is to run the realtime operating system as a module of the general purpose operating system, as described in for example EP 0360135 and the article “Merging real-time processing and UNIX V”, (Gosch), ELECTRONICS, September 1990 p62. In this case, hardware interrupts are selectively masked with the intention that those concerned with the general purpose operating system should not pre-empt the realtime operating system.
Another approach is that of ADEOS (Adaptive Domain Environment for Operating Systems), described in a White Paper.
ADEOS provides a nanokernel which is intended, amongst other things, for running multiple operating systems although it appears only to have been implemented with Linux. One proposed use of ADEOS was to allow ADEOS to distribute interrupts to RTAI (Realtime Application Interface for Linux).
EP 1054332 describes a system in which a “switching unit” (which is not described in sufficient detail for full understanding) runs a realtime and a general purpose operating system. Hardware interrupts are handled by a common interrupt handler, and in some embodiments, they are handled by the realtime operating system, which then generates software interrupts at a lower priority level which are handled by routines in the secondary operating system.